Codecov Report

❌ Patch coverage is 7.69231% with 12 lines in your changes missing coverage. Please review.
✅ Project coverage is 50.39%. Comparing base (a65d4f1) to head (5354f94).
⚠️ Report is 1 commits behind head on 14.0.

@@            Coverage Diff             @@
##             14.0     #894      +/-   ##
==========================================
+ Coverage   50.37%   50.39%   +0.01%     
==========================================
  Files        1175     1175              
  Lines       20100    20098       -2     
  Branches     4271     4271              
==========================================
+ Hits        10126    10129       +3     
+ Misses       9741     9736       -5     
  Partials      233      233              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Closing without merge.

Investigation on test3 (deployed PRs on ./addons/nuobit-odoo-addons per /var/opt/odoo114/repos.yaml: #635, #887, #889, #890 — without #894) confirmed that the "parcialment enviat" email on the first partial MRW delivery already arrives with the tracking number. The race inside stock.picking._action_done (Write A: state=done before Write B: carrier_tracking_ref) is handled by the existing two-export pattern:

1. Flush inside MRW's mrw_create_shipping → message_post triggers _compute_woocommerce_order_state → state promotes to partial_shipped → export Migration to version 12.0 #1 goes to WooCommerce with status=partial-shipped and _wc_shipment_tracking_items=[{tracking_provider}] (no tracking_number yet).
2. Back in send_to_shipper, self.carrier_tracking_ref = res['tracking_number'] triggers the explicit notify in connector_woocommerce_ast/models/stock_picking/stock_picking.py:write → export [12.0][IMP] product_service_time: added tests #2 with status=partial-shipped + full tracking payload.

AST Pro in WooCommerce uses export #2's tracking when firing the shipment email, so the customer receives the email with the tracking number. PR #889's customer_delivered mapping fix (commit 2db327ba) is what prevents an earlier path that would have short-circuited the promotion.

PR #894's state-compute gate was unnecessary and, empirically, broke the timing AST Pro relied on — with #894 applied, the email arrives without tracking. Closing as no-op.

The architectural refactor for a proper stock.picking connector binding (exporter + adapter + mapper) remains tracked separately in task #2567 on nuobit15-prod (Backlog, opt-in cleanup).

🔁 PR reopened — 2026-04-29

Earlier closing was premature. A new field report shows the partial-shipped email arriving without tracking on a recent first-partial delivery (order 19238, 2026-04-28), while a 2026-04-24 reference order (19141) had it correctly. Bug is alive on test3.

Empirical verification on test3

Both exports happen synchronously (delayed=False in listener) — no queue.job rows. The variable is the network/processing latency between Odoo's compute-fired export #1 and AST Pro's email trigger on the WC side.

The race is genuinely timing-dependent, not a deterministic code path. PR #894's gate approach (defer state transition until tracking is set) was empirically observed to consistently produce emails without tracking, suggesting AST Pro relies on the processing → partial_shipped state-change event to fire the email at all.

Path forward

This PR stays open for discussion. Options:

A. Defer message_post inside mrw_create_shipping until after carrier_tracking_ref is written (touches MRW carrier).
B. Suppress export #1 at the listener level when partial-shipped without tracking is imminent.
C. Reorder writes inside _action_done so carrier_tracking_ref is set before the state transition.
D. Configure AST Pro on the WC side to delay or use a different email trigger.
E. Add a flag to export #1 that tells AST Pro "this is preliminary — don't fire the email yet".

Investigation continues. Will update with proposed approach.